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METHOD FOR ISSUING AN ELECTRONIC IDENTITY 



BACKGROUND OF THE INVENTION 

Field of tha invention 

The present invention relates to electronic 
identity techniques and methods. More particularly the 
present invention relates to a novel and improved 
method and system for requesting and issuing an elec- 
tronic identity based on previously certified elec- 
tronic identity. 

Description of the Prior Art 

With respect to securing communication, enti- 
ties are often required to electronically authenticate 
themselves before utilizing services or executing 
transactions- This authenticity may come in the form of 
a usernarcie and password combination or a certificate. 
To accomplish this feat, these entities must first reg- 
ister their existence either physically or virtually so 
that they might receive a proof of identity. 

Providing the proof, such as a username and 
password combination, carries out the actual authenti- 
cation. Aforementioned simple authentication schemes 
are unfortunately quite context specific; identity 
based on username and password may be totally insig- 
nificant in all other circumstances- Moreover, such 
proof does not irrefutably distinguish different enti- 
ties . 

Digital certificates or electronic identities 
are electronic files that are used to uniquely identify 
people and resources over networks such as the Inter- 
net:. With help of digital certificates in is possible 
to make secure, confidential communication between two 
parties. When one travels to another country, his/her 



passport provides a universal way co establish your 
identity and gain entry. Digital certificates provide 
similar identification. Certificates may be issued by a 
trusted third party (TTP) such as a Certification 
Authority (CA) . Much like the role of the passport of- 
fice, the role of the trusted third party is to vali- 
date the certificate holders 1 identity and to 11 sign' 1 
the certificate so that it cannot be forged or tampered 
with. Once a TTP has signed a certificate, the holder 
can present their certificate to people, Web sites, and 
network resources to prove their identity and establish 
encrypted, confidential communications . 

A certificate typically includes a variety of 
information pertaining to its owner and to the TTP that 
issued it. This information can be as follows. The name 
of the holder and other identification information re- 
quired to uniquely identify the holder, such as the URL 
of the Web server using the certificate, an individ- 
ual's email address or the holder* s public key. The 
public key can be used to encrypt sensitive information 
for the certificate holder; the name of the Certifica- 
tion Authority that issued the certificate; a unique 
identifier; the validity period (or lifetime) of the 
certificate (a start and an end date) . 
5 In creating the certificate, this information 

is digitally signed by the issuing TTP . The TTP's sig- 
nature on the certificate is like a tamper-detection 
seal on a bottle of pills - any tampering with the con- 
tents is easily detected. Digital certificates are usu- 
0 ally based on public-key cryptography, which uses a 
pair of keys for encryption and decryption. With pub- 
lxc-key cryptography , keys work m pairs of matched 
"public" and "private 11 keys. In cryptographic systems, 
the term key refers to a numerical value used by an al- 
S gorithm to alter information, making that information 
secure and visible only to individuals who have the 
corresponding key to recover the information- 



The public key can be freely distributed with- 
out compromising the private key, which must be kept 
secret by its owner. Since these keys only work as a 
pair, an operation (for example encryption) done with 
the public key can only be undone (decrypted) with the 
corresponding private key, and vice-versa. A digital 
certificate securely binds your identity, as verified 
by a trusted third party (a CA) , with your public key. 

A CA certificate is a certificate that identi- 
fies a Certification Authority. CA certificates are 
just like other digital certificates except that they 
are self -signed, CA certificates are used to determine 
whether to trust certificates issued by the CA. 

In the case of a passport, a passport control 
officer will verify the validity and authenticity of 
your passport and determine whether to permit you en- 
try. Similarly, the CA certificate is used to authenti- 
cate and validate the Web server certificate. When a 
Web server certificate is presented to a browser, the 
browser uses the CA certificate to determine whether to 
trust the Web server's certificate. If the server cer- 
tificate is valid, the secure session proceeds. If the 
server certificate is not valid, the server certificate 
is rejected and the secure session is stopped, 

In digital environment the contemporary 
equivalent of an identity card is a certificate: a con- 
firmed proof of an entity's distinct identity. A cer- 
tificate typically does more than just confirms attrib- 
utes of its subject. The most common use of (public 
key) certificates is to bind an entity's public keys to 
its identity. These keys can be used to various pur- 
poses such as providing authentication, authorization, 
confidentiality, integrity, or non- repudiation. 

Theoretically certificates are not content 
specific but in practice different uses require differ- 
ent certificates. E.g. standard X.509 certificate does 
not include e-mail address information that is required 
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m secure electronic mail {e.g. PGP or S/MIME) . Simi- 
larly other applications may need to have their own 
proprietary attributes included in certificates. Al- 
though this inclusion of attributes is not problematic 
5 per se, new certificates need to be created, 

US patent 5,982,898 describes a method for is- 
suing a short term certificate for a person who already 
has a previous certificate. The new certificate is is- 
sued after the validation process of the ownership of 

10 the previous certificate. The validation is done by 
separating the tasks of identity verification and cer- 
tificate issuing, which allows a disassociating of the 
long-term binding between the person and his/her pub- 
lic/private key pair- This is accomplished by a regis - 

15 cration authority issuing a password to the person once 
it is satisfied of person's bona fide. Thereafter, 
whenever the person wishes to have a new certificate or 
electronic identity, the person contacts a certifica- 
tion authority, identifies itself with the password and 

20 obtains a certificate. The certificate typically in- 
cludes person's name and a public key m plaintext, and 
a signature. The signature is derived by hashing the 
plaintext portion of the certificate to obtain a value, 
and encrypting the value with the CA's private key, 

25 In order to get a certificate or some other 

electronic proof of identity a subject must prove and 
register its existence to some authority. If the same 
identity needs several proofs for different uses, this 
repeated registration procedure would become quite in- 

3 0 convenient . 

SUMMARY OF THE INVENTION 

The purpose of this invention is to provide 
3 5 means to use a previously certified identity to create 
another representational form for the same identity. 
This representational for can be expressed as an elec- 
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tronic identity, a certificate, or a certificated ac- 
cess to a service or a server. This way an entity, that 
can be defined as a recipient of a electronic identity 
or a certificate or a holder of a certificate, can ex- 
5 tend his, her or its already verified identity for 
other uses. The previously certified identity can be 
for instance so called mobile identity which is associ- 
ated to a person's mobile terminal such as mobile 
phone. The person can show to certificate be his/her 

10 own by using the digital signature feature of the mo- 
bile terminal . 

In the following is an example of the steps ot 
the identity extension process according to the present 
invention. Note that the entities and devices m the 

15 process description are listed by their role and may 
not be distinct ones in practical implementations. 

An entity needs to be authenticated in a con- 
text where it does not have a previously confirmed 
identity. The entity or authorized representative sup- 

2 0 plies optional information that is appended to verified 
facts provided by registration authority that knows the 
entity's mobile identity. 

This information and an identification request 
is sent to the mobile identity registration authority 

25 with routing info to the receiver of identification and 
also to the terminal equipment that contains the means, 
i.e. signing keys to prove the previously confirmed mo- 
bile identity. Based on identification request type 
registration authority appends optional sender-supplied 

30 attributes to verified data that it possesses and for- 
wards these to the specified terminal equipment, if the 
identity cannot be resolved from the terminal routing 
info, the process terminates. 

The entity or authorized representative m~ 

3S spects the accuracy of identification response informa- 
tion on the terminal equipment and if he, she, or it is 
satisfied with it, digitally signs the response after 
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which it is sent back to registration authority, if 
identification type requires additional guarantees, 
e.g. certification, registration authority acquires ap- 
propriate confirmation from providers of those serv- 
ices. Confirmed identity information is sent to the re- 
ceiver address specified in the original identification 
request „ 

Compared to previous registration and certifi- 
cation schemes the most obvious benefit is that the 
present invention offers the same amount of trust that 
a local registration office is capable of providing 
without its physical and other constraints. The equiva- 
lence of trust holds on condit ion that the registration 
authority possesses or has access to corresponding m- 
15 formation, i.e. its private databases or databases of 
other authorities such as Finnish Population Registry 
Center. On the other hand there are also attributes, 
such as access to a certain e-mail address, that can be 
confirmed by virtual means even if these are not re- 
2 0 corded in advance. 

If mobile identity and equipment is used in- 
stead of e.g. a terminal equipped with a smart card 
reader, the solution of the present invention is to- 
tally location independent. An entity can confirm its 

2 5 identity and acquire a new identity whenever and wher- 

ever it is required and is not constrained by the 
available hardware and software provided that the re- 
cipient is capable of receiving the affirmation. Al- 
though the solution does not disallow the use of public 
30 mobile terminals (i.e. somebody else's phone), most 
likely the terminal that is used m authorizing che 
identification response is an entity's own. Conse- 
quently an entity is not required to perform sensitive 
operations, such as entering a signing PIN, on dis- 

3 5 trusted devices. 

Essentially the invention is intended for ex- 
tending an entity's identity based on an existing mo- 



bile certificate and other verified and confirmed 
faces. The one of the most apparent and practical func- 
tions is to use this information to issue new certifi- 
cates for various uses such as secure e-mail, PGP or 
S/MIME. The mobile variant of the solution, however, 
does not have to be as limited. Since the ability to 
provide confirmed facts about an entity is totally mo- 
bile, in certain situations certificates are not a key 
issue. Say, if mobile identity registration authority 
has access to Finnish Population Registry Center [ s da- 
tabase it can provide confirmed home address, marital 
status, or whatever is required. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features, objects, and advantages of the 
present invention will become more apparent from the 
detailed description set forth below when taken in con- 
junction with the drawings wherein: 

FIG, 1 is a block diagram of a system of the 
present invent ion ; 

FIG. 2 is a flow diagram m accordance with 
one embodiment of the invention; 

FIG. 3 is a second flow diagram in accordance 
with one embodiment of the invention 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figure 1 presents one example of the preferred 
system according to the present invention . The system 
of figure 1 includes mobile station MS which is con- 
nected through the communication network CN to the Cer- 
tificate Authority CA server. Also the system includes 
a terminal including for instance a web browser. The 
terminal is connected through the communication network 
CN to the server of CA. The mobile station contains 
means for digital signing a message or character 
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string. Digital signing means x are certified with at 
least one certificate which enables the user to authen- 
ticate more certificates. This previous certificate can 
be a mobile certificate which is mentioned above. 
5 Referring further to figure 1 it is described 

one preferred solution of the present invention. This 
solution is described in the context of certifying a 
new PGP key pair. 

In this solution the following assumptions are 

10 made. The mobile phone's SIM card-signed PGP key packet 
only "lives" for a short time (a few minutes) in the 
system and is then thrown away. If it is logged it can 
be used for journalizing the transactions m the issu- 
ing process. Also it can be logged perhaps for keeping 

15 track of errors. If there were to be any permanent re- 
tention of this packet (for legal or other purposes} , 
it would have to comply with some existing standard 
format, in order to be assured that it could be ac- 
cessed and correctly interpreted in the future. 

20 As described here, the format of the phone - 

signed PGP key packet does not fit any existing stan- 
dard. If necessary, a standard format could be de- 
signed, and the SIM card software would be required to 
create signatures in this format. The user has control 

2 5 (physical security) of the PC and corresponding PGP 

private key used for performing the operations de- 
scribed here. The CA operates a publicly accessible PGP 
keyserver containing all of the PGP keys that the CA 
has signed. 

30 Here we describe the steps to follow m order 

to use the applicants S3 system to securely sign a PGP 
key by the WPKI CA {WPKI, Wireless public key infra- 
structure), using a user - s S3 SIM card to link the sig- 
nature back to the proof of identity that was presented 

3 5 to the WPKI Local Registration Authority, This process 

is performed without breaching the anonymity of the 
user's SIM card Network ID. As described here, the pro- 
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cess is stateless on the CA end, reducing complexity 
and increasing resiliency of the protocol for the CA. 

At first software using PGP on the PC displays 
the name and PGP key fingerprint of the user that is to 
5 be certified on the PC screen. Also displayed on the PC 
display is a prompt to enter the 4 digit number on the 
mobile phone display. 

The PGP key fingerprint is a cryptographical ly 
strong hash of the key. PGP users are accustomed to 
10 verifying keys by comparing key fingerprints, so this 
makes it easier to verify the PC-Phone link is reli- 
able, and not being attacked by an intruder inserting a 
fake message to be signed by the phone, The latter is 
probably not necessary to protect against, since we as- 
15 sume physical security for that link. However, the link 
is not necessarily secured. 

The PC software communicates with the phone 
through the wired or wireless interface or other appro- 
priate interface, and passes a message packer (TBD) 

2 0 containing a command to start the PGP key signing proc- 

ess . Phone generates and displays a four digit random 
number, along with a prompt to cype this number into 
the PC if the user wants to sign his PGP key with his 
phone key. 

25 The phone displays a 4 digit random number 

that then mast be manually entered into the PC r s key- 
board- This prevents a daring (high probability of de- 
tection) attack from a hostile device that might be 
communicating with the phone , and trying to trick it 

3 0 into signing a "What is my name?' 1 message that could be 

used to compromise the NID's anonymnity. 

Then user types in the 4 digit number from the 
display on the phone into the PC, as requested by the 
screen prompt . 

35 ° n the PC, the software takes the 4 digit ran- 

dom number entered by the user, and sends it with a 
message, intended to be sent to the CA, requesting 
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(from the CA) a User ID lookup for a phone NID char 
signed the request. Ia other words, a "What is my 
name?" request. 

The phone compares the random number sent with 
the 11 What is my name?" request; and if it matches, dis- 
plays a warning that it is about to sign a PGP key with 
its key. 

PC displays a lengthy legal notice to user, 
warning that user is about to sign their PGP key with 
the phone's key and that the user is contractually ob- 
ligated to only make this signature if he is the owner 
of both keys. Again, if the random number matched, the 
"What is my name?" message is signed by the phone, re- 
turned to the PC through the serial interface, and 
saved for transmission to the CA, The PC software gen- 
erates another message, intended for transmission to 
the CA, this message contains the key fingerprint, and 
a request to the CA to sign the attached key, if the 
fingerprint matches. This is a "Sign this User ID and 
key, please," request. The n Sign this User ID and key, 
please," message is then passed to the phone through 
the serial interface, with a request that the phone 
sign the packet, using the its SIM card private key. 

The PGP key fingerprint is displayed on the 
phone at this point and verified by the user to be m 
agreement with the PGP key fingerprint on the PC 
screen. The user is prompted to OK the signature, if 
the fingerprint matches. The User's phone sends the 
signed "Sign this User ID and key, please." packet back 
through the serial interface to the PC [along with the 
phone key ID that signed it] . Save on the PC for later 
transmission to the CA. The PC-Phone connection is no 
longer needed after this point, and is dropped. 

Note that if desired, the process described m 
the preceding few steps could be accomplished with only 
one signed message from the phone. This message would 
contain a signature of the PGP key fingerprint. The one 



message would be used with two different meanings , 
first no ask the CA, "What's my User' ID (name)?", and 
second to command it to "Sign this Key and User ID 
please 11 . In the first case the PGP key fingerprint is 
ignored, since only the phone's NID is need to specify 
what name is desired from the CA. 

The PC opens up a secure channel (using TLS) 
to the Certification Authority, The PC sends the SIM- 
signed request for User ID ("What's my User ID and 
name? 11 ) query to the CA over the secure link- 

The CA looks up the phone's owner m the con- 
fidential database, and sends the User ID for the phone 
back to the PC, as requested. This is the WPKI User ID 
that the phone 1 s owner had certified at the LRA. Send- 
ing this information to the PC does not breach the ano- 
nymity of the NID, since the link is encrypted and the 
phone owner xs the one making the request , 

The PC checks to see if the returned WPKI User 
ID is present on the users PGP key. If it is, then the 
process proceeds to the next step, automatically. If 
the returned WPKI User ID is not present on the PGP 
key, then the User ID is added to the PGP key before 
proceeding . 

If the WPKI User ID must be added to the PGP 
key, we branch off at this point and follow the normal 
PGP procedure for adding a new User ID to one's key- 
ring. The user must supply an email address for this 
User ID, because the User ID supplied by the CA will 
not have an email address. 

Since the ultimate result of this process will 
be publication of the signed key on a public keyserver, 
the User ID must be self -signed. PGP User IDs are only 
suitable for publication if they are signed by the 
key ' s owner . 

The PC next uses the user's PGP private key to 
sign the " Sign this key, please. " request to the CA 
(this request is asking the CA to sign the phone 



owner's PGP key, remember). This request was signed 
earlier by the phone's SIM card. 

This signanure shows the CA that the requestor 
is the one who controls the PGP private key component, 
and is not sending someone else's key for certifica- 
tion. 

The PC sends the PGP and Phone signed Sign 
this User ID and Key, Please." request packet with the 
corresponding PGP key up to the CA, through the estab- 
lished TLS link, Again, this packet links the phone 
owner's (presumably anonymous) NID with the public PGP 
identity, so the channel must be encrypted* 

The CA checks the PGP signature . The CA checks 
the phone key. The CA then checks in its confidential 
database for the User ID associated with the phone that 
signed the "Sign this Key, Please," request. The sub- 
mitted PGP User ID (name portion) must match with the 
CA r s phone's user name. This will be the case, because 
we ]ust added the User ID returned by the CA for this 
NID to the PGP key we attached to the message . 

If the submitted User ID for this phone is not 
found in the CA*s confidential database, the request is 
denied, and an error message is sent back to the PC 
For debugging purposes, this error message could con- 
tain the correct User ID, since we are operating over 
an encrypted channel. The user is informed of the prob- 
lem via an error message displayed on PC. If the name 
portion of the User IDs match, then the CA signs the 
PGP key with the CA key and discards the "Sign this 
key f Please" request with the phone NID - It then in- 
serts this information into the confidential database. 
The CA- signed PGP key is added to a « Pending PGP Cer- 
tificate' 1 database on the CA. 

The CA then emails the CA- signed PGP Key to 
the email address specified by the user in the User ID 
that was signed by the CA. This provides a check that 
the email address is correct. This certificate is en- 



crypt ed by the public encrypt ion key of that user. That 
way if the email address turns out to be wrong, and the 
key is misrouted, It will likely never be decrypted by 
anyone , 

The CA expects the user to decrypt and re- 
upload the signed key back up to the CA r thus proving 
that the email address was correct, and the person re- 
siding at that email address has the capability of de- 
crypting with that key. When the CA receives this key 
back from the user, the CA purges it from the Pending 
PGP Certificate database. To overcome email delivery 
problems , periodically the CA will repeat the previous 
step until the user responds or until the CA decides to 
give up. 

When the CA receives this key back from the 
user, the CA publishes the resultant signed PGP key on 
its PGP key server. The PGP key is signed only with the 
LRA-verif ied User ID, of course. None of the other 
UserlDs that the user might have on his pgp key are 
signed by the CA. Note also that the telephone NID is 
not part of the PGP key, nor is it published with the 
PGP key, so we are still protecting the user's NID- 
related anonymity. 

Figure 2 presents one example of the flowchart 
of the present invention. First the need for any addi- 
tional data is checked, state 21- The additional daca 
can be user's current and previously issued certificate 
or 3ome other information like the name or the e-mail 
address of the user. If any additional information is 
needed then the user will provide it, stare 22. Then 
the request for identification is sent to the registra- 
tion authority CA, state 23. According the identity in- 
formation the existence of any previous identities is 
searched, state 24- This search can be made m the pri- 
vate databases of the registration authority or data- 
bases of other authorities- If any previous identities 
is found then a response is created and sent to speci- 



fied terminal, state 26. If any previous identifies is 
not found then the information needed . is acquired from 
the user. If the user accepts the response he or she 
signs it digitally and sends it back to registration 
authority, states 27 and 28. If any additional guaran- 
tees are required then those can be acquired from ap- 
propriate authorities, stares 29 and 210. Finally the 
confirmed identity information is sent to specified re- 
ceiver, state 211. 

Figure 3 presents one example of the certifi- 
cate of the present invention. The certificate contains 
a number of information, which are required for the 
identification. Typically such information are certifi- 
cate identification number, user name, users e-mail ad- 
dress , RSA/DSS keys, the fingerprint of the signature 
or of the certificate itself, nhe hash of the 
passphra.se, the signature, and the expiration dare of 
the certificate. 

The previous description of the preferred em- 
bodiments is provided to enable any person skilled in 
the art to make or use the present invention. The vari- 
ous modifications to these embodiments will be readily 
apparent co those skilled m the art, and the generic 
principles defined herein may be applied to other em- 
bodiments without the use of the inventive faculty. 
Thus, the present invention is not intended to be lim- 
ited cq the embodiments shown herein but is to be ac- 
corded the widest scope consistent with the principles 
and novel features disclosed herein. 
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1. Method for issuing an electronic idencity 
for an entity from an idencity registration authority, 
the method comprising the steps of: 

a) issuing a first electronic identity for said 

entity; 

b) creating a request for a second electronic 
identity for said entity, the request including an 
identifier of said entity; 

C) sending said request to said identity regis- 
tration authority; 

d) in response to said request, creating an 
identification response; 

e) sending said identification response to said 

entity ; 

f) verifying an acceptability of said identifi- 
cation response by said entity; 

g) in response said verifying, if said identi- 
fication response is acceptable, signing digitally said 
identification response by said first entity; 

h) sending said signed response to said iden- 
tity registration authority; 

i) verifying a validity of said digital signa- 
ture and said identification response in said signed 
response ; and 

2) in response to said verifying, if said digi- 
tal signature and identification response are valid, 
issuing a second identity based on said first identity. 

2. The method of claim 1 further comprising a 
second entity by which said first entity digitally 
signs said identification response, 

3. The method of claim X or 2 further compris- 
ing the steps of ; 

checking if the information of said second en- 
tity is available using said identifier; and 



in response said checking, if said information 
is not available, inquiring the information of said 
second entity from said first entity. 

4 - The method of claim 2 or 3 wherein said sec- 
ond entity is in control of said first entity. 

5. The method of claim 3 wherein said informa- 
tion of said second entity comprises one or more from 
the set containing a unique address of said second en- 
tity, the name of the holder of said second entity and 
previous identity or identities of said second entity, 

6. The method of claim 1 further comprising the 

step of : 

establishing and encrypting a communication 
channel between said first entity and said identity 
registration authority to ensure confidential communi- 
cation there between. 

7. The method of claim 1 further comprising the 

step of: 

storing said issued second identity to the da- 
tabase of said identity registration authority . 

8. The method of claim 1 further comprising the 

step of: 

storing said issued second identity to the da- 
tabase of the issuer of said first electronic identity, 

9. The method of claim 1 further comprising the 

step of: 

combining said first and said second electronic 
identities to form a combined electronic identity; and 

storing said combined electronic identity to 
the database . 

10. The method of claim 1 further comprising 
the step of; 

sending said issued second identity to said en- 
tity. 

11. The method of claim l further comprising 
the step of: 



sending said issued second identity to a third 

partly. 

12 . The method of claim 1 before the seep of 
issuing said second identity further comprising the 
steps of : 

checking if additional guarantees for ensuring 
a validity of the first identity are to be acquired ; 
and 

m response to said checking, if additional 
guarantees are needed, acquiring additional guarantees . 

13. The method of claim 1 further comprising 
the steps of: 

adding a time stamp to said issued second iden- 
tity; and 

storing said time stamped second identity to 
the database of said registration authority. 

14. The method of claim 1 further comprising 
the step of; 

adding into said time stamp a expiration date 
of said second electronic identity. 

15. The method of claim 1 further comprising 
the steps of; 

adding a notarization to said issued second 
identity; and 

storing said notarized second identity to the 
database of said registration authority. 

16. The method of claim 1 further comprising 
the steps of; 

inquiring a further identifier code to be added 
into said signed identification response 

receiving said identifier code at said regis- 
tration authority; and 

verifying the validity of said identifier code 
at said registration authority. 

17. The method of claim 16 wherein said identi- 
fier code includes one or more from the set containing 
biometric code of said first entity, a predetermined 
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character string, a f mgerprint of the entity's public 
key, random number, certif icate f and a. hash code of the 
shared secret: between said first entity and said regis- 
tration authority. 

18. The method of claim 1 further comprising 
the steps of: 

creating a first hash code from said identity 
request at registration authority ,- 

sending said first hash code to said second en- 
tity; 

creating a second hash code from said identity- 
request by said second entity; and 

verifying a validity of said first hash code by 
comparing it to said second hash code before the sign- 
ing of said response. 

19. The method of claim 1 or 2 before the step 
of issuing further comprising the steps of: 

sending a confirmation message to the address 
specified in said additional information of said en- 
tity; 

receiving a confirmation response to said con- 
firmation message at said registration authority; and 

verifying the validity of said confirmation re- 
sponse , 

20. The method of claim 19 before the step of 
issuing further comprising the step of: 

canceling said issuing of said second elec- 
tronic identity if said confirmation response is not 
received in a predetermined time period. 

21. The method of claim 1 wherein said request 
for issuing said second certificate for said entity is 
initiated by said third party. 

22. The method of claim 1 wherein said request 
for issuing said second certificate for said entity is 
initiated by said second entity. 
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23. The method of claim 2 wherein said request 
is digitally signed by said first entity before sending 
said request . 

24- The method of claim 2 wherein said request: 
5 is encrypted before sending said request. 

25. The method of claim 1 further comprising 
the step of: 

journalizing a log of all transactions during 
the issue process of said second electronic identity. 

10 26. The method of claim 2 wherein said second 

entity is one of the following set including mobile 
terminal, mobile phone, personal computer, set-top box, 
smart card, tamper proof device, security token, soft- 
ware agent, pager, terminal equipment, and personal 

15 digital assistant (PDA) , 
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A method for issuing an elec- 
tronic identity based on previously cer- 
tified elect romc identity. This is ac- 
complished by providing a method to use 
a previously certified identity to cre- 
ate another representational form for 
che same identity. This way the holder 
of a certificate can extend his or her 
already verified identity for other 
uses- The previously certified identity 
can be for instance so called mobile 
identity which is associated to a per- 
son's mobile terminal such as mobile 
phone. The person can show no certifi- 
cate be his/her own by using the digital 
signature feature of the mobile termi- 
nal . 
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